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PREFACE 


NASA traditionally has recognized the need for responding promptly to un- 
solicited proposals for research and development. A three month average is 
the goal for either rejecting a proposal or beginning procurement action. 

The Office of University Affairs, as the responsible office for handling 
unsolicited proposals, established in the early 1960's a manual tracking and 
follow-up system to ensure effective proposal processing. 

til 

The newly installed "n generation" system presented here, therefore, rep- 
resents a distillation of some 15 years of proposal-handling experience. 

The techniques which have thus emerged provide easy visibility to each organ- 
ization's proposal handling activities. As a result, both the participating 
organizations and NASA management can identify areas of good performance and 
situations calling for improvement. 

While this report concentrates on the ADP aspects of the proposal system, 
necessary related background material allows an overview of proposal activi- 
ties- The system, itself, may be of use to other organizations with similar 
proposal responsibilities, or, indeed, for application in its more general- 
ized function as A correspondence control system. The system will function 
well for a wide rcinge of incoming items, such as mail inquiries, which must 
be distributed foir action, tracked and disposed of on a reasonable time 
scale. 

NASA centers, other agencies or outside organizations desiring further infor- 
mation on the proposal handling system should contact: 

National Aeronautics and Space Administration 
Office of University Affairs, Code P 
Washington, B.C. 20546 


vi 



Copies of the Programmer's Manual and Source Programs are available for sale 
from NASA's Computer Software Management and Information Center (COSMIC). 
Information regarding price and order forms may be obtained by contacting: 


COSMIC 

Suite 112, Barrow Hall 
The University of Georgia 
Athens, GA 30602 
Telephone: (400) 542-3265 
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ADP CORRESPONDENCE SYSTEM : 

UNSOLICITED PROPOSAL EVALUATION TRACKING APPLICATION 
Users Manual and Documentation 


I. INTRODUCTION 

The Office of University Affairs (OUA) is responsible for handling unsolic- 
ited proposals sent to NASA by educational institutions. Agency policy en- 
courages the unsolicited proposal technique for establishing NASA-University 
relationships; this concept is maintained through ensuring acknowledgement, 
prompt evaluation, and timely notice to the proposer of acceptance or re- 
jection. The mainstay of this process is a computerized system for control- 
ling the proposal flow. 

An understanding of the ADP system developed for proposal tracking is more 
easily gained by considering the context in which proposals are reviewed 
and decisions made. NASA is a mission-oriented agency which funds proposals 
only when the work is good, the effort meets a long- or short-range mission 
need, and, of course, there are sufficient funds available in the scientific 
or engineering area represented by the proposal. Two important points, 
thus, emerge: (1) nothing is funded as "assistance," and (2) decisions as 

to mission applicability must be made by people intimately familiar with de- 
tailed mission requirements. 

A. Proposal Review Process 

The resultant process is summarized in Figure 1. Proposals are received 
by the OUA, acknowledged, and forwarded for evaluation to the NASA instal- 
lations which have a potential interest in the proposal. Only one repre- 
sentative installation is shown in the figure; however, there are some ten 
of these throughout the country. The proposal is evaluated (by techniques 
beyond the scope of this report) and a decision made either to accept or 
reject. If it is accepted, the procurement action is requested, an award 
is made to the school, and the OUA is notified. 
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Figure 1. Unsolicited Proposal Handling Relationships 
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The acceptance process differs from rejection. All acceptance is decentral- 
ized. Any NASA installation reviewing a proposal may fund it and work di- 
rectly with the school. It is not necessary for all reviewing installations 
to "report in" before a proposal can be funded. However, if an installation 
rejects a proposal it notifies OUA; if all reviewing installations indicate 
rejection, OUA formally notifies the proposer. 

B. Proposal Review Follow-Up 

The NASA goal is for all proposals to be evaluated and responses provided 
within three months of receipt. If the proposal is for continuation of an 
on-going project, response should be made before the ending date of the 
effort underway. To achieve these results, follow-up is required. With 
some 2,500 individual proposals handled each year, manual effort must be 
minimized. Thus, the present ADP system provides a monthly listing describ- 
ing proposals under evaluation, responsible installations, and the length 
of time each proposal has been under evaluation. Each reviewing installa- 
tion receives a listing showing only its own proposals. However, each re- 
viewing installation also receives an extensive tabular analysis of evalua- 
tion times throughout the agency. Several breakouts are presented so the 
recipients may conduct as detailed an examination of their proposal activi- 
ties as might be necessary in achieving satisfactory performance. 

C. System Design Concepts 

Proposal handling is primarily a bulk processing clerical operation which 
must be accomplished quickly and accurately by a small number of people. 

The accompanying ADP system is designed to fit easily into this environment. 
Thus, practically no knowledge of ADP is required of those who input mate- 
rial and up-date the system. There is extensive automatic editing to de- 
tect errors in the material input. When an error is detected, a simple 
message describes the nature of the mistake. When an error does occur, the 
entire input cards for the proposal are rejected to avoid complicated cor- 
rections on parts of records. The accuracy level of the system is held to 
that generally experienced in clerical operations to avoid needless "over- 
editing." 
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A "post-audit" or back-up file maintenance capability is provided so the 
supervisor of the proposal-handling group has direct access to the data to 
make over-ride corrections, as required. The final control on accuracy is 
obtained from the users of the monthly lists. Their detailed reviews 
quickly reveal minor discrepancies which are readily corrected by file 
maintenance . 

D. Other Applications 

The proposal system is actually a specialized version of a more general cor- 
respondence handling system. In this sense, its main advantage is optimi- 
zation from the standpoint of the user, i.e., simplicity of input, edit, 
correction, and output. In general it is adaptable to any paper handling 
process involving the basic questions of: Who sent it? When? Who is sup- 

posed to reply? Did they? How long does it take to act? 

The ease with which the present techniques may be used in their more gener- 
alized sense is illustrated in the Appendix, Part C. A brief design descrip' 
tion of a correspondence handling system is developed as an illustration. 

The remainder of this report will be devoted to a detailed description of 
operating the proposal system (clerical level) and of the system itself 
(design parameter level). Some of the general information on system reports 
may be of interest to all readers. 

II. SYSTEM REPORTS 

A good feel for the proposal system can be had from examination of the out- 
put reports, particularly those intended for the proposal reviewers. The 
inventory listing and the statistical analyses are in this category. A file 
listing and several measures of items handled are used for internal purposes 
only. 


A. Inventory Listing 

A separate section of the inventory listing is available for each office 
reviewing a particular proposal. Figure 2 is a typical sample of the list. 
Features of special note are: 


4 






1 . 


The center line of the heading specifies the office responsible for 
evaluating the proposals. ("SL" is the abbreviation for the Planetary 
Programs Division in NASA Headquarters.) There is a similar section 
for each of the 30-odd reviewing offices and field installations. 

2. The length of time under review is calculated from the date of receipt 
by NASA and the as-of-date of the report. The proposals are grouped 
under header labels which specify the length of time the proposals have 
been under review, i.e., less than 3 months, 3. 0-5. 9 months, etc. 

3. Each entry consists of a proposal number, name of submitting institu- 
tion, proposal title, and name of proposal principal investigator. 

4. If the proposal is for continuation of an on-going project, this is 
indicated by either listing the prior agreement number (NSG-9009 in 
Figure 2) or "continuation proposal" when the prior number is not 
readily available. 

5. Proposals are dropped from this list whenever a reviewer rejects or 
funds a proposal, i.e., the evaluation is completed. If a review 
states the proposal will definitely be funded at some later date it is 
dropped from the regular inventory and placed on an "intent-to-fund" 
list (Figure 3) . The implications of this category will be discussed 
in a later section. 

Every three months (or more frequently if necessary) each reviewing office 
is sent a copy of its inventory list. This alerts the office to overdue 
evaluations, i.e., proposals under review for more than three months, and 
provides a ready mechanism for correction of any errors in the inventory 
list itself. The comments column is designed for this latter purpose; it 
is not intended as a substitute for a complete evaluation report on the pro- 
posal. The "intent-to-fund" (Figure 3) variation on the inventory is dis- 
tributed as a reminder that procurement requests must be prepared for the 
listed proposals. 

B. Analytical Tables 

The analytical tables are quite complex, but are intended for use only by 
the individual in each installation who has particular management responsi- 
bility for analyzing institution proposal evaluation performance. 
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Figure 3. Intent-to-Fund Proposal Inventory Variation 



The tables are "re-set" each year, i.e., analyses are only produced for ac- 
tivity occurring during the current fiscal year. Proposals received during 
the prior year are, of course, carried over into the new fiscal year if 
evaluation has not been completed. It is important to note that the tables 
show evaluations due; this is not the same as the number of proposals under 
review, as many proposals are reviewed by several offices. For this reason 
the last line on each table shows both the number of evaluations and the 
(smaller) number of proposals involved. 

The content of the analytical tables is best understood by examining the 
tables themselves. Therefore, an entire analytical report is reproduced on 
the following pages. Figure 4 is a prefatory page while Figures 5-10 
(Tables I-VI) are the basic tables. There are subsets to Tables I-IV and 
VI (not illustrated here) which subdivide the information on proposals for 
new awards (subset A) and proposals for continuation of on-going work (sub- 
set B) . They are identical in format to Tables I-IV and VI, but are dis- 
tinguished by use of the A or B designator and a plain English statement in 
each table heading. 

Figure 4 provides a capsule description of the contents of each table. It 
should be studied carefully by those using the tables in detail, as very 
important distinctions among the tables are made. 

Table I provides a count of all proposals which are still under review. 

Table II shows tallies of proposals accepted for funding and Table III con- 
tains the totals for proposals which have been rejected by all NASA review- 
ing installations. Table IV offers an overview of all the types of proposal 
activity during the fiscal year including the data from Tables I-III. It 
should be noted that this table contains additional statistics on negative 
evaluations, i.e., negative reports on proposals which have not yet been 
rejected by all installations. Therefore, Table IV will never reflect the 
exact total of Tables I-III. 
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Figure 4. Analytical Tables— Preface 
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Figure 5. Analytical Table I— Active Proposals 
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Figure 6. Analytical Table 1 1 -Acceptances 




12 


Figure 7. Analytical Table I II— Rejections 
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Figure 8. Analytical Table IV— All Actions 
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Figure 9. Analytical Table V— Intent to Fund 






Table V is a special case. When a reviewing office completes an evaluation, 
but cannot fund an accepted proposal immediately, it is not fair to the of- 
fice to count the proposal as "under evaluation." On the other hand, if 
the promised funding does not materialize, the proposal slips into limbo. 

The intend-to-fund list, by establishing a middle position, avoids both of 
these problems. An "intent" proposal stays on this list until it is funded. 
The age shown is still calculated from the date of receipt by NASA. In the 
event any of the intent proposals gets unduly old, follow-up to complete the 
funding action (or to change the status) is readily accomplished. 

Finally, Table VI presents counts and percentages for all categories of 
evaluation activity by each office. This table can be used for workload 
analysis at any given time. The percentages are calculated to reflect the 
total workload distribution of NASA evaluation activity. Thus, the percent- 
ages are calculated using the total proposals received (663 in this table) , 
which results in the following figures: percent of evaluations under review, 

70.4%; percent rejected, 10.2%; and percent accepted, 19.3%. The percent- 
age expressions for "completed evaluations" can be calculated by using the 
proposal totals, 68 rejected and 128 accepted, which result in 34.6% and 
65.4%, respectively. 

C. File Listing 

The heart of the proposal system is the file list report. It uses most of 
the information in the system data base. (See the Appendix, Part A, for 
data base layout.) Figure 11 is a typical file listing page. All of the 
items shown are taken directly from the data base, except for "age," which 
is calculated. Individual items on the list are: 

1. Control Number . These are assigned sequentially upon receipt of the 

proposal. The file listing is arranged in order by the control number 
which serves as the file identifier. (In the example, there are miss- 
ing numbers as this file listing represents the first period of a FY 
and contains only those proposals carried over from the last FY for 
which evaluations have not been completed.) 
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Figure 11. File Listing 



Institution (Name) . Standard names for each school, maintained on a 
separate listing (OUA-MIS UNICODE System), are used. Considerations 
of sorting and retrieving by university name are discussed in the 
Appendix, Part A. 

Revcode, Disp., Mo-age . The three parts to this grouping are: 

a. Reviewing Code — This is the symbol for the office evaluating the 
proposal. A maximum of 6 office codes may be listed. 

b. Disposition — There are three possible entries: "D" indicates an 
office has rejected a proposal; "F" indicates funding; and a 
blank means "no response." Whenever an "F" is entered for one 
office, all remaining blanks are automatically changed to "D" to 
indicate that no further evaluation is required. 

c. Mo-age . — This is the age in months it has taken a particular of- 
fice to review a proposal. It is calculated from the date a 
proposal was sent to an office and the date a disposition (see 
above) response is received. Where a proposal is still under re- 
view the file "as-of" date is used instead of the disposition 
date. 

DT-RCVD/DT-SENT . The top date in this column shows when the proposal 
was received by NASA. The next 1-6 dates indicate when it was physi- 
cally sent for evaluation to each reviewing office listed. 

DT-DISP . A disposition date enters the file each time an evaluation 
is completed and an "F" or "D" placed in the "DISP" column. The dis- 
position date is used in calculating how long a proposal has been 
under evaluation. 

Proposal Title . The title is shown exactly as presented by the pro- 
poser. Titles exceeding the limit of 264 positions are truncated. 
CONTINUATION OF . When an extension proposal is received, the identi- 
fication number of the grant/contract is entered. If the proposer 
does not indicate the I.D. number of his current agreement, C" is 
entered where the proposal is obviously a continuation request. 
INVESTIGATOR . The name of the principal investigator proposed by an 
institution is entered. A total of 15 positions are available for the 
name. For longer names, initials and finally the name itself are 
truncated . 



9. IN FD . "Intent-to-fund" status is indicated by an "I." (See last 
proposal in Figure 11.) 

10. PROCOST . The cost in dollar amounts requested by the proposer is given 
for each proposal. 

11. CASE, OB, FS . (Reserved for CASE data. See Appendix, Part A.) 

D. Activity Tracking 

Two additional tabulations are available for analyzing the proposal work- 
load. A counter (Figure 12) at the end of the file listing analyzes the 
file contents in terms of proposals (not individual evaluations) . All ac- 
tive proposals (new and continuation) are shown regardless of their fiscal 
year of receipt. The completed proposals (funded and rejected) are only 
those for which action was taken during the current fiscal year. "Intent" 
proposals, by definition, are active and, therefore, totalled in the active 
column. 

The table shown in Figure 13 tallies monthly proposal actions in terms of 
receipts, fundings, rejections, and the amount of funds requested. "Rejec- 
tion" here signifies a negative response on the part of all evaluators. It 
only shows data for the current fiscal year. (The first two months of FY 77, 
which begins October 1, 1976, are illustrated.) 

in. SYSTEM FLOW 

Understanding of the' activities leading up to the previously described re- 
ports production is best gained by following the life cycle of a proposal. 
This chapter provides an overview of the normal flow of activities from the 
time a new proposal is received until evaluation is completed. The various 
input forms and activities required to support the tracking system are de- 
scribed briefly. Detailed instructions for completion and use of the input 
forms are provided in Chapters IV and V. 

A generalized view of proposal flow was presented in Figure 1. Figures 14 
and 15 give more detailed flow pictures needed to understand the actual 
"hands on" ADP aspect of the proposal system. The external flow or 
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Figure 12. File Listing Counter 
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Figure 14. NASA Proposal Flow and ADP System Interfaces 
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environment is covered by Figure 14 while Figure 15 details the internal 
flow within the Office of University Affairs, i.e., the heavy-bordered area 
of Figure 14. As a matter of simplicity of illustration, universities ap- 
pear twice and installations appear three times in the external flow dia- 
gram. Each appearance represents the same organization but in a different 
role. 

The annual volume handled by the depicted system amounts to some 2,000 new 
proposals submitted by about 300 universities. Any given proposal may in- 
volve one or more of NASA's 10 installations. 

A. Receipt of New Proposal 

The process begins with receipt by NASA of a valid unsolicited proposal from 
a university. (Definitions of "valid" and "unsolicited" are beyond the 
scope of this report and are not critical to understanding the ADP process- 
ing.) Any proposal which has not been acted upon previously by NASA is con- 
sidered to be a new proposal, i.e., a request to continue a previously 
funded project is a new proposal, not a change to the proposal upon which 
the project was originally based. 

NASA instructions require that proposals be sent by the universities di- 
rectly to the Office of University Affairs (OUA) . Occasionally, a proposal 
will be sent to a NASA installation (dashed lines in Figure 14) which, in 
turn, forwards it to OUA. Regardless of the path taken, the handling upon 
OUA receipt is the same: preparation of a "Proposal Status Record," NASA 

Form 172. 

B. Completion of Form 172 

The Form 172 is the key element in both the ADP and manual aspects of the 
proposal handling system; hence, it will be extensively discussed. Errors 
in its preparation can dog the proposal during the entire evaluation and 
disposition cycle. It is a manifolded or "snap-out" form with seven copies 
and interleaved carbon paper. Each copy is slightly different, tailored to 
its specific use in the system. The entire form is depicted in Figure 16. 
System functions for each copy are briefly described. 
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Figure 16. Proposal Status Record (Form 172) Manifold Set 


1. Original , white. Complete descriptive information, plus the initial 
evaluating offices, is entered. The original is then detached and 
filed manually by institution. No further typed entries are ever made, 
only manual ones. 

2. Acknowledgement , white. Receipt of the proposal is acknowledged by 
mailing this copy (Figure 17) to the sender. The blacked out areas 
conceal the identity of the evaluators and internal coding which might 
confuse the sender. The back of the form, shown as Figure 18, is a 
brief acknowledgement letter. 


25 






















INSTITUTION 

DATE RECEIVED 

CONTINUATION OF 


UN IV WISC-MILWAUKEE 

09-08-75 

NGR 50-007-001 

PROPOSED COST 

PRINCIPAL INVESTIGATOR 

DATE ACKNOWLEDGED 

PROPOSER'S CONTROL NO. 

$ 32,980 

TANOW, T. 

09-08-75 

76-040-NM 


PROPOSER’S 
FILE COPY 


PROPOSAL TITLE 


UNSTEADY VISCOUS IN COMPRESSIBLE AND COtfPRESSIBLE FLOW AROUND 
HELICOPTER ROTOR BLADES. 





r 


PRO- Mr. John T. Sheel, Director 
POSal^. Office of Grants and Contracts 

The University of Wisconsin - Milwaukee 


SENT 
IN BY 


L 


Milwaukee, WI 53201 


n 


J 


This record copy acknowledges re- 
ceipt of the proposal described above. 
Further information is on the back. 


NHQ DIV FORM 172 nov 74 previous edition is obsolete. 


2- ACKNOWLEDGEMENT 

Figure 17. Form 172 Acknowledgement (Copy 2, Front) 


Your proposal is now being evaluated by NASA's technical staff. A brochure containing additional details 
on proposal preparation, submission and review is available upon request. Note that our receipt and reten- 
tion of the proposal does not place an obligation on the Government to pay any cost incurred in its prepa- 
ration and submission nor for any work started before a support agreement is awarded. 

We appreciate your desire to contribute to NASA's programs and will notify you of the results of our evalu- 
ation as soon as it is completed. 

Please cite the "NASA Control No." in communications regarding this proposal. Inquiries should be ad- 
dressed to: 

Proposal Control Officer 
Office of University Affairs 
CodePY 

National Aeronautics and Space Administration 
Washington, O.C. 20546 


Figure 18. Form 172 Acknowledgement (Copy 2, Back) 
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3 . 


ADP Input Data Copy , pink. This is the Form 172 input shown in the 
system flow diagram. Figure 15. It is designed for keypunch "as is," 
and direct input to the system. Only data and instructions of concern 
to the keypunch operators are shown. The pink copy (Figure 19) is 
used only to input information about new proposals at the time of in- 
itial receipt processing. Once it has been submitted it is not to be 
removed from the "stack" for change or additions. Any errors detected 
after preparation are corrected elsewhere by the procedures described 
in Chapters IV and V. 
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KP Notes: 

1. Put File I.D. (cc 1-11) on all cards. 
H 2. Punch “R” cards only when there 
are some data in cc 12-50. 

3. Punch as is. 


3-ADP INPUT DATA COPY 


Figure 19. Form 172 ADP Input Data Copy (Copy 3) 
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File Copy , yellow. This copy (Figure 20) is placed in the official 
file containing the proposal and other paperwork generated during the 
evaluation process. 
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Figure 20. Form 172 File Copy (Copy 4) 
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Distribution Copy , white. One copy of the form (Figure 21) goes with 
each proposal package sent out for evaluation. It is similar to copy 1, 
except that it is designed to be used for file purposes by the recipient. 
Thus, room is provided for the evaluators to note their "action," in 
lieu of the "Rec'd" and "FDI" areas needed by OUA. Copies 6 and 7 are 
identical to Copy 5. If distribution is made to more than 3 evaluators, 
photocopies are made; an additional 172 is not typed. 
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5 -DISTRIBUTION COPY 


Figure 21. Form 172 Distribution Copy (Copies 5-7) 
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C. Secondary Distribution 

Following the initial distribution of a proposal, the original evaluators 
may submit comments to OUA which would lead to the proposal’s being evalu- 
ated by more offices. This is shown as "additional reviewers" under Evalu- 
ation Results in the flow chart, Figure 14. This information is added to 
the data base on Transcript No. 18, Secondary Proposal Distribution, as 
shown in Figure 22. At the same time, copy 4 of Form 172, resident in the 
official proposal file, is modified by hand to show the additional distri- 
bution and date. 



Figure 22. Secondary Distribution Transcript (T. 18) 


D. Evaluation Results 

In addition to the request for additional distribution, evaluation results 
are of two types: terminal and interim. A terminal result is either a de- 
cision to fund a proposal or to reject it. (Rejection may only be on the 
part of that evaluator, not necessarily on the part of NASA.) An interim 
decision, or "intent-to-fund" is a definite statement that the proposal will 
be funded in the near future, pending authorization to use monies for the 
proposal. These decisions enter the system on Transcript No. 19, Proposal 
Evaluation Received (Figure 23) . 
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Figure 23. Evaluation Results Transcript (T. 19) 


Fund, reject or intent is indicated by F, D and I, respectively. At the 
same time an installation prepares an "F" evaluation, a purchase request 
is forwarded to its local procurement office, thus initiating the process 
leading to award of a grant or contract. 

Sometimes an installation will by-pass normal procedures by taking a di- 
rectly received proposal and initiating procurement action without inform- 
ing OUA. The horizontal dashed line in the flow chart. Figure 14, is an 
oversimplified representation of the path. The situation comes to light 
when a "notice of pending procurement action" reaches OUA. Since the evalu- 
ation has been completed, no entry is made in the ADP system. Alternately, 
the system will allow submission of both a Form 172 for a new proposal and 
a transcript entry indicating funding. The information on the action would 
be retained for the remainder of the fiscal year. This course, however, is 
rarely followed as the system is operated primarily to ensure prompt han- 
dling of active proposals, rather than to provide statistics on all proposals 
handled. 
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The three steps described above — new proposal receipt, additional distribu- 
tion, and evaluation — complete the description of the input and processing 
actions of Figure 14 and the data input in Figure 15. The "output" part of 
Figure 15 involves little ADP activity. It is shown primarily for complete 
ness and requires no further discussion. 

E. Error Correction for Data Input 

The system has integrated edit and update processing. This means that if 
the data inputs are correct, they will go into the data base; on the other 
hand, no incorrect information will be accepted. It will be rejected and 
printed in an error report. Each report will indicate the nature of the 
error so that it may be corrected and the entire input made again. In the 
case of a Form 172, it takes only one major error to cause all of the data 
on the form to be rejected. The entire form must be resubmitted. 

The system does not edit for certain types of minor errors; thus omission 
of the principal investigator's name or a mispelling in a technical descrip 
tion does not cause Form 172 data to reject. Correction in such instances 
can be made by the system supervisor through the "override" or file mainte- 
nance techniques described in Part H, below. 

F. Deletions 

All data associated with a particular proposal may be permanently deleted 
from the system by a Transcript No. 20 entry (Figure 24). 

Deletion is used sparingly, as it is required only in unusual circumstances 
viz., withdrawal of a proposal, inadvertent entry of a non-university pro- 
posal or improper proposal number. When a proposal is deleted, its control 
number should not be re-used. If several actions against a proposal have 
already been submitted, such as Form 172, secondary distribution and evalu- 
ation received, it is not necessary to locate those items and remove them 
from the input. The deletion action is extremely powerful; it takes prece- 
dence over all other actions. 
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Figure 24. Deletion/Name Change Transcript (T. 20) 
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CARD ID 







G. Office Code Changes 

There are two general circumstances under which proposal evaluator review- 
ing codes must be changed. 

1. Responsibility for proposal evaluation changes. In this instance the 
originally assigned reviewing office may be "closed out" by entering a 
"D" evaluation result, while the new reviewer's code is entered as 
secondary distribution. Alternately, the system supervisor may substi- 
tute one code for another by the file maintenance techniques (see Part H, 
below) . 

2. Reorganizations frequently result in recoding offices, but no change 
in review responsibility. This may affect hundreds of file entries — 
too many to be conveniently handled by changes to each proposal record. 

In this case provision is made on the bottom of Transcript No. 20 for 
changing all affected records at once. This change may be made at any 
time. It is a powerful "override" which adjusts not only records al- 
ready in the data base but also new input which is submitted at the 
same time as Transcript No. 20. 
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Figure 24 Repeated. Deletion/Name Change Transcript (T. 20) 
(Bottom Portion) 


H. File Maintenance 

The System Supervisor has direct access to the data base to make any correc- 
tions or changes desired to maintain system accuracy. Transcript No. 22, 
Basic Proposal Maintenance, is used. This transcript, however, must be 
used only in conjunction with the most recent file listing. That is, only 
data already on the file list may be changed. In a properly managed system 
the need to use this input mechanism will be minimal. There is an exception: 
if a proposal previously classified as "intent-to-fund" is subsequently to 
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be rejected, the intent flag on the file must be removed by inserting an 
asterisk in column 57 of the TC card, as illustrated in Figure 25. A de- 
tailed discussion of the extensive File Maintenance (FM) techniques appears 
in Chapter V. 

1. Activity Counter 

The inventory and analytical reports and the file listing outputs have been 
-previously described. The final housekeeping output which completes the 
description of the Figure 15 system flow is the activity counter. This 
counter. Figure 26, tallies the input for any particular update, less any 
erroneous cards which may be rejected. 
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Figure 26. Input Activity Counter 
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Figure 25. System Supervisor File Maintenance Transcript (T. 22) 






























The "new proposals" entry Is a count of the Forms 172 input, while the re- 
maining entries are line-by-line counts of the items entered on the various 
transcripts. This counter is essential to proper system management, as it 
allows the Supervisor to determine if all input is actually going into the 
system when program validation or revalidation may be necessary. It also 
highlights certain unusual error conditions in which cards can "vanish." 

The counter appears as the last item on the error/update report. 

J. Processing Schedule 
1. Weekly Updates 

The system normally should be updated weekly for ease in editing 
and error correction. When both proposal and evaluation receipts 
are low, reduction of the update frequency to three times or even 
twice a month may be acceptable. For weekly updates, input nor- 
mally consists of Forms 172 and transcripts. These are sent to 
the computer room with the special External Source Data Input 
Submittal form shown in Figure 27. Items 4 and 8 on the form 
are critical to the proposal system operation. 

Type of input (item 4) alerts the computer operators to what 
types of material are attached, i.e., Form 172, Transcript, or 
Card. Forms 172 and transcripts are the normal weekly input 
items. However, it is desirable to have as much as possible key- 
punched in advance to avoid delays when an update run is actually 
ordered. In this event all three types of input would be checked, 
or perhaps only "card," if everything had been keypunched in 
advance . 

In item 8, "update files" is normally checked for the type of run 
requested. The as-of-date entered governs the age calculation 
of the proposals. Thus, for weekly updates the as-of-date should 
reflect the latest date that input material was prepared. The 
"prior FY ended" is preprinted on the forms and need not be changed 
during weekly update. 


37 



NATIONAL AERONAUTICS ANO SPACE ADMINISTRATION 

EXTERNAL SOURCE DATA INPUT SUBMITTAL 


SECTION I TO BE COMPLETE’) BY THE SUBMITTING OFFICE f S— InafiucHona ow ravaraa) 


' SU8-SYIT KM TITLE 

OlIA Proposal System 

1. AS/OF DATE 

5. PILE I D. 

4- TV PI or INPUT (Card, tap«. low i, ate.) 

Form 172 X Transcript Card 

» CONCERNING THE DATA NOW BEING SUBMITTED AS INPUT ON THIS PILE 
1. D. POR THIS AS/OP DATBi 

(Chack 0*0 column on mc/i It am) ] 

werm 

NO I 

* C. ir NO IS CHICKKO O * 
ITEM B.. INDICATE BELOW 
WHEN REMAINDER OP BJ B> 
MISSION CAN BE EXPECTED. 

e. no. or item* or input 

A. WERE PARTIAL SUBMISSIONS 
MADE PRIOR TO THIIONKT 

m 

s 

7 . disposition or input items 

Return to originator 

8. DOES THIS SUBMISSION 

COMPLETE THE TOTAL INPUT? 

m 

■ 

TIME OATS 


• ■ REMARKS 


Run Requested (Check one ): 

X UA01 Update Files (Monthly or as required) 


UA02 


Bnd-of-Year Purge Run (Annual only: Deletes all 

completed proposals) 


Dates (Enter both ) : 


As-of-date 
Prior FY ended 


Mon Day Yr 


/ 

»|0 

7\f 

0 \(o 

3\0 

7 |£ 



to. or pi c k cool 

P 


11. TIME AND OATf SUBMITTED 

it/ii/Tsr 


SECTIOI 


COMPLETED by DATA PREPARATION SECTION 


12. ROUTING 

19, LINE ITEM COUNT | 

\t4. LOG. NO. | 

| IB. PRODUCT COOE | 

10. PRIORITY j 

1 

17. OUE DATE 

IS. RECIPIENT 

IS, ACTUAL COUNT 

20. PEL EASED TO 

| 2 t . TIME AND DATE RELEASED 




NASA PORM SS auo «7 namuacc* nho form as. psa «7, which may ac uaan. 


Figure 27. System Update Request 
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All output reports are produced during weekly update, but only 
the error report is of major concern. Any rejected data should 
be corrected by preparation of the proper cards for use in the 
next week's update. It is essential that these corrections be 
entered before the system is updated again, lest over-all accu- 
racy deteriorate. 

The other reports, particularly the file listing, should be 
given a quick review just to ensure that the system is still op- 
erating properly. If the report is being produced in response to 
a special request for current information it should, of course, 
be checked thoroughly before release. 

2. Monthly Update 

Monthly reports are produced in the same manner as weekly ones, 
except that the as-of-date is always entered as the last day of 
the month. It is very important that proposals and evaluations 
received during the month be input and the reports produced and 
distributed promptly. Thus, on the morning of the last working 
day of the month all transcripts and Forms 172 should be sent for 
keypunch, in order to finish by the morning of the second working 
day of the month. Upon receipt, the cards and all additional 
input required for the remainder of the month should be sent in 
for file update and reports production. 

3. Year End Processing 

The proposal system has a continuing component of proposals under 
review, and a periodic or fiscal year component, viz., acceptances 
and rejections. The active proposals are kept in the system un- 
til they are either funded or rejected. The completed proposals 
are dropped at the end of each fiscal year. 
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To 


a. 


b. 


c. 


d. 


illustrate, the following actions set up the system for FY 77. 
Run the last monthly report (update files) for the year just 
ending. The as-of-date and the "prior FY ended date" will 
read 09-30-76 and 06-30-76, respectively. 

Ensure that the system has operated and updated properly. 
Request an "End-of-Year Purge Run." Do not input any data 
with it. The as-of-date will be 10-01-76 and the "prior FY 
ended date" will be 09-30-75. 

Check for proper purge: 

— The monthly activity counter (Figure 13) should be blank. 

— The funded and completed columns of the file listing 
counter (Figure 12) should be blank. 

— The Disposition and Date of Disposition columns on the 
File List (Figure 11) should be blank. 

— The accepted and rejected columns on Tables VI, VIA 
and VIB should be blank. 


The "purge" need not be physically run on the first day of 
the new year; however, failure to purge will result in errone- 
ous or misleading file updates. If new input is submitted 
before the purge, the blank areas mentioned above might con- 
tain data. Once the purge is made, the data submittal form 
(Figure 27) should be reprinted with the new "prior FY ended 
date." All forms with the old date must be destroyed . 
(Inadvertent use of the wrong "prior" date will not do per- 
manent harm to the data base. However, it will destroy the 
validity of the monthly activity counter for that particular 
run. ) 


IV. INPUT FORM PREPARATION 

This chapter contains detailed instructions on when and how to use the Pro- 
posal Status Record, Form 172, and the input transcripts. In addition, it 
discusses the types of errors the computer will detect. Samples of each 
error message are given. 
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A. Preparation of Form 172 

1. When to Prepare 

The Proposal Status Record, Form 172, is completed when the follow- 
ing actions occur: 

a. A new proposal is received from the proposer. 

b. A new proposal is received from a Field Installation Office 

or another NASA Office wishing to review the proposal. (In this 
case, the receiving office would be included in the list of 
reviewers) . 

c. A receiving office expresses an "intent-to-fund" a newly re- 
ceived proposal. (A Transcript No. 19, indicating "intent," 
would also be prepared). 

d. A receiving office indicates a decision not to fund a new 
proposal, but suggests (or OUA decides) that additional dis- 
tribution should be made. (The receiving office would be shown 
on the list of reviewers, but an evaluation received of "D" 
should be entered on a Transcript No. 19). 

2. General Instructions — Preparation of Form 172 

a. Use 12-space-per-inch typewriter. 

b. Keep all entries within their own blocks. 

c. Use margin and tab sets for automatic spacing. 

d. If an erasure or correction is necessary, make sure copy 3 
for ADP is legible. 

If a 172 is prepared in error it is not necessary to locate the 
ADP copy and destroy it. Merely request the Systems Supervisor 
to process a delete action against the proposal number. That par- 
ticular proposal number should not be reassigned. 
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3. 


Specific Completion Instructions 



Figure 16 Repeated. Proposal Status Record (Form 172) 


Block 

NASA Control No. 


Institution 


Date Received 


Procedures 

Typed on dotted line. Must be entirely nu- 
meric, i.e., control number cannot contain 
hyphens, commas, or blanks. Extreme care 
must be used to avoid using the same control 
number more than one time. 

Standard university names, providing complete 
identification of school and campus, are used. 
A maximum of 25 letters and spaces are avail- 
able. A current university list of "short 
names" is maintained by the Office of Uni- 
versity Affairs (See Figure 28). 

Use stamp-in date for proposals received di- 
rectly by OUA. For proposals sent via field 
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Figure 28. Standard University Name List (UNICODE Type 2A) 



Continuation of 


Proposed Cost 

Principal 

Investigator 

Date Acknowledged 

Proposer's Control 
Number 

U 

Proposal Title 


Eval. Code 1-6 


installations, use date received by installa- 
tion or the closest available approximation to 
it. The style for all dates is 00-00-00. 
Grant/contract to be extended, as noted in 
proposal. Must be with same grantee/contractor. 
Maximum length is space available. May be 
blank. 

If proposal is obviously for continuation, but 
prior grant/contract number is not available, 
type "C" in the box. It is not necessary to 
consult other documents to see if the prior 
number can be located. 

Use total amount requested in dollars. Write 
with commas. 

Use surname followed by comma and given name 
or initials. 

Use date of OUA acknowledgment . 

Maximum length is space available. Can be 
more than one line, if necessary. 

Enter "U" for proposals from colleges and uni- 
versities. Leave blank for proposals from 
any other source. 

Maximum size is 66 spaces — to dotted line — 
and 4 lines deep. Computer will ignore every- 
thing else. Avoid hyphenating words at the 
ends of lines. 

Reviewer's code. Cannot exceed 5 characters. 

At least one must be filled in. Use only those 
codes on Approved Distribution Code List (Fig- 
ure 29). If more than 6 offices are on dis- 
tribution consult the Proposal Control Officer 
to ensure that the 6 primary reviewers are 
listed. The remaining reviewers and dates 
sent should be noted by hand in the margin 
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Approved Distribution Code List 
(As of October 29, 1975) 


Headquarters 

Centers 

AA* 

NT 

ARC 

AC* 

P 

FRC 

AD* 

RA 

GSFC 

BX* 

RB 

JPL 

E* 

RE 

JSC 

EC 

RL 

KSC 

EE 

RO 

LARC 

EK 

RP 

LERC 

EP 

RR 

MSFC 

ER 

RS 

NSTL 

ES 

RT 

WFC 

ET 

RW 


FE 

RX 


K* 

S* 


KC 

SB 


KT 

SG 


MF* 

SL 


MK* 

ST 


MT* 

SU 


N* 

T 


NE 

U 


NS 



NOTE: 

Only approved codes may 


used on Form 172 or tran- 
scripts. Use of asterisked 
codes or any unlisted code 
requires approval of code P. 


Figure 29. Approved Distribution Code List 


45 



Eval. Date Sent 1-6 


Rec'd & FDI 


Proposal sent in by 


after copies 2 and 3 have been removed. The 
evaluation code blocks may be used in any se- 
quence. For less than 5 evaluators, use of 1, 
2, 4 and 5 is suggested as automatic spacing 
is available for these blocks. 

Date proposal is sent for review. There must 
be a date for each evaluation code shown. If 
the proposal was received directly from a 
field installation, use the date (or close 
approximation) proposal was received by the 
installation. Date of OUA distribution should, 
of course, be used for any other evaluators. 
These are rarely used when 172 is being ini- 
tially completed. (Entries in these blocks 
will not go into the computer.) However, after 
the 172 set has been separated and the original 
put in the file, the date a review is received 
will be entered. The type of review is indi- 
cated by F (funded), D (rejected), or I 
(intent-to-fund) . 

In special cases, when the evaluation results 
and date are available at the same time a pro- 
posal is entered into the system, the Form 172 
is completed in the normal fashion and a 
Transcript No. 19 entry is made to record the 
evaluation results. 

Name and mailing address of the proposal orig- 
inator. Keep within the space marked, so the 
address will show in a window envelope. 


4 . Error Messages 

Up to 8 IBM cards result from a single Form 172 input. The re- 
lationship between the typed information and the card numbers 
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(PI - P6 and up to two R1 cards) may be seen on Copy 3, Figure 19, 
which is repeated below. Each of these cards is subject to sev- 
eral machine edits. If any one card does not pass edit, all the 
cards related to a particular Form 172 are rejected. The 172 must 
then be resubmitted. 
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Figure 19 Repeated. Form 172 ADP Input (Copy 3) 


A typical edit list with error messages for Form 171 appears in 
the middle of Figure 30. Note the X's under the proposal number, 
4123; they are underneath the material in error. The problem is 
described in the message "no such proposal number." This, of 
course, is true since present proposals have 5 digits in the 60,000 
series. Correction here involves not only correcting the ADP rec- 
ords, but the official file and any other place the erroneous pro- 
posal number may have been used. 
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Figure 30. Common Error Messages 
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Figure 30 (Continued) 



The same scheme is followed in the next three examples where the 
errors are "proposal number previously used," "U not entered," and 
"no reviewing codes." Note in each case how an X appears beiow 
the error and all other information entered on the Form 172 is 


printed out. 


The examples shown below are variations on an edit used for all 
dates. Any missing dates or impossible ones, such as 08-34-75, 
will be rejected. 


e <733 AkU ona» tMii jf 

ccfb-* * *• uo-tJ- 75 u 

acihj l oAu - «* A V C L t \L l ti ^ h L 7 L b t I n t i_r The oKiChJcSl STARS, 

o 2733 oL 

A AAAAAAA 

o* 75*» b I I J So CrvGh , IMV cf kio-ii- /pNul- jS-C 1 1 -U3G FI 

o 2/34 Joj ituouOC 4 1 V f - , c » R. LO- 2 S— 7iL P 2 

lmoCKmTuKY STuCl ti lN T ht cau ImT iciH AM, CCLLISIONAl ll- AC f I vA T 1 ON P3 
02/34 ob ML I*STAdLfc AILMS AAL I'lLtluLCb IN Tbt AURORA 4 M3 AlktiLLn. PA 

oc7a*» it, uO-J-*-75Sl lB-14-73 R1 MISSING LR BAD DATE SENT 

XAAAAAAA 


PI 

Pi 

P3 

Rl MISSING CK BAD CATE SENT 


The next two proposals listed, 62755 and 62758, contain multiple 
errors. Here it may be seen that all errors produce messages and 
X's even though it only takes one error to cause a 172 to be 
rejected. 


Cl '/33 

ClkAEll CMVtRilT'r wo-io-73 

PI 


t2 733 

J2i39 JCbftSuh* b»* h. od-2o— 75 

P2 

U NOT fcNTLKED 

C 2 i 33 

AlrltTorsAL Cb.AkAL ILhWaII ui« u t H Yuftuo tN ATTACK. 

P 2 


02733 

ARC 

AAA AAAAA 

Rl 

MISSING CR BAD DATE 

02 733 

J fc-i fc- 7 5 

Rl 

NO REVIEWING CODES 


AaAAAAAXAAXXA 



02 ( 3o 

lift 1 troUKV , LiiiV Lb uj-wJ- 73 

PI 


t2 7 3o 

2'icCO tvERSHfaN* m. OJ-D3-75F 

P 2 

U NOT ENTERED 

Cl 730 

SILLY lP Tbt PklPALoTIlN ob ouLM. ti\ ACMjMPCRM CELTS. 

P 5 


c2/3o 

LcKl J3-C3-/5 

Rl 



Note that 62758 is similar to 62751 (Figure 30). In one instance 
the space for "U" was blank; in the other, the wrong letter, "P," 
was inserted. In either event the edit recognized "U not entered." 

B. Secondary Distribution, Transcript No. 18 
1. When to Prepare 

Transcript No. 18 is used whenever a proposal is sent for evalua- 
tion to an office which was not originally listed on Form 172. At 
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the same time the transcript is prepared, the new evaluating of- 
fice should be marked on the 172 in the official proposal file. 

2. Specific Completion Instructions 



Figure 22 Repeated. Secondary Distribution Transcript (T. 18) 


Block 

Proposal No. 
Distribution to 
Date Sent 
Card I. D. 


Procedure 

Enter proposal number starting at arrowhead. 

Only numbers may be used. No hyphens or letters. 
Enter appropriate code from approved list (Fig- 
ure 29), starting under the arrowhead. 

Date of OUA distribution. Style is 00-00-00. 
Hyphens must be used. 

Extend wriggly line as far down the page as 
there are entries to the left. 


3. Error Messages 

The edit procedure for Transcript No. 18 is similar to that for 
the Form 172, except that only a single entry is rejected when 
there is an error. Various types of rejected cards and the rea- 
sons are given below. As with the Form 172, the correction con- 
sists of making a new transcript entry with the proper information. 
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CARD If.! 






Nc» lo cRRCRS 


tltii LS“wP-7p 

A>)AAAAA>)A 


R 2 NC SUCH PROPOSAL NUMBER 


The message "No such proposal number" for this transcript example 
usually occurs because there is an error (either on the transcript 
or in keypunch) in the proposal number, with the result that the 
illustrated 61212 cannot be found in the proposal data base. In 
correcting this type of error the file listing should be checked 
to see if such a proposal number is actually there. For instance, 
a Form 172 may have been prepared but misplaced before going into 
the data base. 

ctso lS-1j-7a ' ki DUPLICATE OR BLANK REVIEWING CODE 

aaaaa 

cs-cf-7a R c DUPLICATE OR BLANK REVIEWING CODE 

AAAAA 


"Duplicate or blank reviewing code" is a double check. For 62698 
and 62700 a date is given for the additional distribution, but the 
code has been left out. 


ui. 7 c ■> Ajl. 

AAAaA 


R £ CUPLICATE OR BLANK REVIEWING CODE 


c^7lj 


j ct IS- Ip- 7 5 
A A A AAaaa 


R2 MISSING CR BAD DATE SEN T 


For 62703 an attempt has been made to add additional distribution 
to KSC, but KSC is already listed as an evaluator. This error 
could result from KSC inadvertently being entered twice as an addi- 
tional evaluator or could be the result of a typographical error, 
viz . , KSC for JSC . 

7*L7i At C9-.J-75 RE TCC MANY REVIEWING CODES 

aaaaa 
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The "missing or bad date sent" message is the same sort of analysis 
previously mentioned in the discussion of the Form 172. The error 
in 72071 arose because there are already six evaluating offices 
for the proposal. This was determined by examination of the master 
file. This is a proposal-handling problem, not an ADP problem; it 
should be brought to the attention of the Proposal Control Officer. 

C. Evaluation Results, Transcript No. 19 

1. When to Prepare 

A Transcript No. 19 entry is required whenever an evaluation indi- 
cating rejection, funding or intent-to-fund is received. Proper 
preparation requires that the proposal file be consulted prior to 
completing the transcript. 

2. Specific Completion Instructions 



\ 


Figure 23 Repeated. Evaluation Results Transcript (T. 19) 


Block 

Proposal Number 
Evaluation from 


Procedure 

Enter proposal number starting at the arrowhead. 
Only numbers may be used, no hyphens or letters. 
Enter evaluating office code exactly as shown 
on Form 172 in the file. If distribution has 
not previously been made to an office which 
indicates rejection of the proposal, no tran- 
script entry is required. If, however, the 
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Date 
D, F 


Card 


office not on the file is funding or intends to 
fund the proposal, two transcripts must be pre- 
pared: Transcript No. 19 to show the evalua- 

tion results and Transcript No. 18 to enter 
the receiving office code. 

Received Date OUA received evaluation. Style is 

00-00-00. Hyphens must be used. 

or I If the proposal file does not have a previous 

"intent-to-fund" evaluation, merely enter D 
(reject), F (funded) or I (intent-to-fund) de- 
pending upon the evaluation. When an intent- 
to-fund is specified, enter D for all other 
active reviewers on distribution. If the re- 
sults of an evaluation are vague, i.e., D, F 
or I cannot be clearly specified, do not make 
a Transcript No. 19 entry. Evaluations of this 
nature should be brought to the attention of 
the Proposal Control Officer. 

If the proposal has had a previous "intent-to- 
fund" evaluation, and funding is now available, 
an F may be entered in the normal manner. If, 
however, a second evaluation from the office 
originally indicating "intent" shows that fund- 
ing will not actually be made, enter a D and 
notify the Systems Supervisor that the intent- 
to-fund signal must be blanked out. (Asterisk 
in cc 57 of the TC card on the System Super- 
visor File Maintenance Transcript No. 22.) 

I,D * Extend the wriggly line as far down the page 

as there are entries to the left. 
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3. Error Messages 

Messages associated with Transcript No. 19 are illustrated below.' 
They are similar to those discussed previously, particularly the 
"missing or bad date received" and the "no such proposal number." 
The "D, F or I not indicated" will appear if the wrong letter has 
been entered or column 31 of the Transcript No. 19 has been left 
blank. 

oii'tV ill o-7d i K 3 

AAAAAAAA 

ciio/ cis CS-jU-72 k 2 

A 

Oilic M.M vS-^w-75 L K 2 

AAAAAAAAA JA 

tllou ubtt, iS-iJ-7; i k'J 

AAaaa 

Note that here, too, X's highlight the location of the errors. 

The error in 62756, "Code not on distribution," illustrates a prob- 
lem which can result from making a transcript input without look- 
ing at the actual distribution in the official proposal file (or 
on the proposal system master file listing). 

D. Special Proposal Maintenance, Transcript No. 20 

Transcript No. 20 is divided into two independent parts, the top half 
(card 4) used for deleting proposals and the bottom (card 5) used for multi- 
ple reviewing code changes. 

1. Deletion 

Entering the proposal control number and as much wriggly line as 
needed in the card ID column (R4) is all that is necessary to re- 
move the entire record of a proposal from the data base. There is 
only one edit message, "No such proposal to delete." This will 
occur if the proposal number entered on the transcript does not . 
match a proposal number on the file. Figure 31 shows two errors. 
Item 3 will not match, as it is an invalid number containing a 
letter. Item 4 will reject since it is improperly placed, covering 


MISSING CR BAD DATE RECEIVEO 

o » f f ur i nut indicated 

NX SUCH PROPOSAL NUMBER 
CCCE NCT UN DISTRIBUTION 
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six rather than five spaces with a blank in place of the first 
number . 



Figure 31. Deletion/ Name Change Transcript (T. 20) 

(Top Portion, Card R4) 

2. Multiple Code Changes 

Use of this capability only requires entering the old code, the 
new code and the wriggly line as shown in the bottom (card R5) of 
the transcript. 



Figure 31 Repeated. Deletion/Name Change Transcript (T. 20) 
(Bottom Portion, Card R5) 
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When this is done all evaluating codes on the file which match the 
old code — including any coming in at the same time on 172 's or 
other transcripts — will automatically be changed to the new code. 
Self-explanatory error messages which might appear are as shown. 

1 K *1 fs 1 F I lie* C w cnhC^i 

ni NE V. CODE not INDICATED 

Kb NC ciu c cuts TO CHANGE 


A A A AA 

rr u 

A A A * A 


A maximum of three code change instructions may be input in any 
particular file update batch. Entering six code change cards simul- 
taneously will result in the error message illustrated below. The 
first three change cards were accepted, but the last three were 
rejected. 


t.-. -LKiiCrs i 


- i K 

A A A A A 

cNfc OiFt 
-...XAJULA .. 

t-AKl — i-titii. 
XAAAA 



hi .. ... 

... TuC WANT CUDE CHANGES 


R5 

TCC MANY CCOE CHANGES 


X* 

. . TUO .MANY _C CJ)£. CHANGES. 


V. SPECIALIZED INPUT ACTIONS 

The bulk of the transcript preparation and related error analysis activity 
has been described in the previous chapter. In addition, certain actions 
such as those related to "intent-to-fund" require action by the Systems 
Supervisor (Proposal Control Officer). This chapter is devoted to these and 
other important, but low-volume, actions which will generally be handled only 
by the System Supervisor, rather than the data or proposal clerks. 

A. Card I.D. Difficulties 

The first example is the "Card I.D. in error" section on the input edit list. 
This analysis is always the first item on the list. The message, "A key- 
punch error occurred," means that the card number is missing or invalid as 
indicated by the XX' s. 
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cJLk.1 cl. in r'J r 


REASON .REJECTED 


L flKu lu IN cKhUft .. ... .. ... 

t z/^7 ARC v.j-^-3 -Iz A KEY PUNC H E RROR OCCUREO 

XX 

OiLlvJ ..rfANtti* UcsLCN* .... . ..A KEY PUNCH ERROR OCCUREC 

XX 

_.C£./.oJ _ l f i CN i T U*-' Y iif. Kt*J. TCKdlNt. CL AC c.S. EuK.. EoTuR E _AU A KEY PUNCH ERROR OCCUREO 

XX 

tz LuA Ai? l_ -Li.--* Lt.IZjLI Lii zjLLzlxhQ iu ~ *LzJX A KEY P UNCH ERROR OCC UREO 

XX 


The Systems Supervisor must re-input all of these data on the proper tran- 
script. The appropriate card number can be determined by analyzing the input 
edit list itself. Thus, in the above example, the first item rejected is 
obviously a multiple review in code change and should be re-input on Tran- 
script No. 20 as it is an R5 card. The next two, 61122 and 61212, have in- 
formation typical only of a delete action, i.e., the only entries are the 
proposal control numbers. This information would also be re-input on Tran- 
script No. 20 using the R4 card. The final one, 61256, is readily seen as 
an attempt to enter an evaluation result of "F" for the office code "ARC." 
This would be re-input on Transcript No. 20 using the R3 card. Note that in 
all of these cases it is not necessary to use any proposal file. All the 
required information is obtained from the edit input list, combined with a 
knowledge of the proper use for each transcript. 

B. 80/80 Input Card List 

Each time the system is updated an "80/80 listing," an exact image of the 
keypunched cards, is produced. In normal operations this list is not used. 
However, it is invaluable in tracking down those errors where it is neces- 
sary to compare what went into the computer with what came out. Input tran- 
scripts or 172's are not reliable for this purpose as there may have been 
keypunch errors or a card may have been lost. As an example, the input card 
list shown as Figure 32 corresponds to the data which resulted in the edit 
list error messages shown in the example above. The missing card ID's 
(circled on Figure 32) are seen to be the exact ones producing the keypunch 
error messages in the "Card I.D. in error" section of the input edit list. 
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INPUT CARL LIST 


PM L 
F f 
4 ioi 
41 03 
4 k; 
4103 
61100 
01149 
01167 
Ololo 
ololo 
01010 
01010 
tl05o 
O1073 
ol 0 73 
c 10 73 
oi073 
01089 
£1089 
0 lo69 
01089 
0 lo4o 
o0696 
00 700 
6o7£j 
O0 7u3 
OO703 
co75U 
60 730 
00 730 
00730 

00730 

00731 
oO 731 
00731 
o 0 7 3 1 
60750 
oo750 
00730 
oO 7 50 
co 753 
cO 7 3 3 
oO 733 
oo 7 33 

00 7 34 
00/54 

01 734 
00734 
oO 734 

00/33 
to 733 
£0733 
co 755 
oO 733 
co 7 3o 

£0 730 
60 7 So 
£0 7 5o 
£0756 
00 730 
60758 
60758 
60758 
00 758 
70 C 71 
90051 


MINN, L-MINNP-ST PALL Oo-oo-/3 
7o449 LAMBtkT, K. F. 63-UJ-75U 

SPATIAL FILTERING MtThcLS If. FcUkCULI ACOUSTICS. 
LARL 03-C3-75 

So 03-73 I 

EH C 9- 30-7 5 


AKu 89-03-73 

MM CS-oO-75 0 

MIAMI UNlVtHSlTY 
ARC U9-16-75 F 

FtCtKAL CITY CULLtCt 
08889 FRIEOMAN, C. 


Uj— lo- /3 noa-u 9— C50-0 13 
o3-o9- 75U 


ClNvErSILN CF MIMS TC FLKIRmN iv A 03 TRACT* 
PY U3-15-75CSFC 03-19-73 


MlLECULAP MCCtL FLR CRYSTAL on 
PY 1o-03-74U7-0j-73C 
05-15-73 
C9-C7-75 
nSC CS-Co-75 

JSC 15-15-73 

L ERl 

VlRulNlA, LMV uF Uo-UJ— 

74948 PARK 1 SF , t. A. 

AN 1NVE3T IGATluN LF PLT twT I aL 
SAMPLcU ANALCO PRCCESSLR. 

LARC 88-03-75 

Calif, u-S Barbara uo- 14 - 

35470 FE ALE , S. J. 

SCLAR SYSTEM PFYS1CS. 

SL UO-19-/5SG C8-i9-/jMM 

F.AkAll, INI) OF Uj-17- 

50cj9 FCLSCMt, C. 

N-HtltkuCYLLlC CLMPCUNUS: RUi. 

UN 17) MBTLCRiTES ANC A3 PRUUU6 
ArIOCNA, GN1N CF Uo-oJ- 

01/05 klSNltkSM, k. 

LONG— kAVtLENCTH FFL I CMt TRY cF 
So 

PITTSoCKGH, CM V CF uo-oi- 

ooUuO /IFF, t • R. 

LABORATORY STUCltS CN TF.E cacI 

cF McTASTAbLB ATOMS ANU TiuLcc 
SC 88-34- 7 3SL 86-04-/3 

CORNELL UNIVERSITY Uo-00- 

joO;9 JCFnSuN, h. h. 

STRUCTURAL C FAKAcT tR 1 / aT iota ur 
8 o— 0 6-/5 

ARC 

Ul) kloC-M ILwAUREt 89-uo- 


6 0-8 3- 7 58 

mPPLIcATICNS OF OP-SAPS-OPERaTIUNAL 


73 nuk-u5 -C 10-060 
Co- lo-75 

jo-i3-73 
?3NuR— 10-C01-1C9 
jj- 14-75U 

c In CHEMICAL EVCLUTICn: U1STR16UTI 

T 3 cF 3PARK CISCHARoES. 

7 3 

J6-03-75U 

The onIOFIcST STARS* 

?3N6L— 39— 01 1-030 
6 8 - 04 - 758 

TATiciM ANC CCLLIS1CNAL UE- ACT I VAT I ON 
uLc3 IN THt AURORA ANC AlRCLCR* 


86-0 c- 7 5 

hYUtvUCEN ATTACK. 


TANJk, T. 


7 3 1 , 6 a 3C-CC7-CC1 
CV-wc— 75C 


UNSTEACY VISCOUS INCOMPRE 33 loc c AnU COMPRESSIBLE FLCk ARUUNO HELIC P3 
CFTER RUIOR ECACES. P4 

LARC 09-C8-75 R1 

L-SFC 05-oJ— 7 5 C R3 

CANTERBURY, LMV CF 63 - 83-/3 PI 

09OCC EvERSMAN, k. C3-U3-75P P2 

STLCY LF 7 F E PRCFAGAT ILN ut SuUNU In NCNUNIFORM DUCTS. P3 

LERC U3-U3-/5 R 1 

SG CS-OO-75 R 2 
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C. Proposal Number Duplication 

If two new proposals are inadvertently assigned the same proposal number, 
the system will reject the second one, provided both 172 's are not submitted 
at the same time in the same update batch . 


If the duplicate proposal number is entered on the same date or even within 
a few days of the first entry, a special error condition results which must 
be resolved by the Systems Supervisor. 


The clue that the same proposal number may have been assigned shows up in the 
input edit list example given below: 

hCnM 1/2 t riKLih S 


/p o . TcAtip* uNiV-AUiTIN VKI - MO— /PiVPi* - PI 

- — ..... .._ VI U NOT ENTfcHED 

A 

... .... . *1 NO. REV lEw.l.NG..CUD.fcS 

AAAAAAAaAAAAA 


There is too much information missing from this proposal. Here it is im- 
portant to look at the 80/80 list to determine exactly what cards were input. 


INPUT CAHC LIST 


At SG 



R5 

AMU Arif 



R5 

AH SL 



R5 

Am SM 



R5_ 

GNFC GSFC 



R5 




R5 

t2 75 o 

TfcAASi UMV-AUSTIN 

Oo-vo- 7;>»>ob- pOQ 5 

PI 


n i ij n r i n i c n li fy i v 

l)o-Zla-7p KliK— <* 7-CQi-0k^ 

PI 

6275o 

11555 LAMoEtU, 

U. L. u b— u 7— 7 5 U 

P2 


Ci_ AY . F . 

P. on-*. 1-75U 

P < 

C275u 

ANALYTICAL STUDY CF 

T hfc CPTiMuM ot uM cT R I C CCMF IGUR I CM UF 

A SPACE P 3 


LUS EkvAT LLhb ilE FH 1SS i LiM 1 li» iA ^UPkKGAAM S.« 

P3 

t2 7 56 

SHLTT Lt MATERIALS 

LAECKATukY. 

PA 


1 Ak(. 


R 1 

to i. 75o 

ES 0 tt— 22- 7 5 


R 1 

tc75o 

i*SFL — ub~i l-l 5 

- 

R 1 


Figure 33. Input Card List Related to Infrequent Error Conditions 


Reference to proposal 62756 shows immediately what has happened — a Texas, 
Univ-Austin, and an Old Dominion University proposal were given the same con- 
trol number. It is not possible to tell what information belongs to each 
proposal. 

Retrieval of the original Forms 172 from the manual file (Figures 34 and 35) 
shows that the Texas proposal was numbered 62756 on August 6, while the Old 
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Figure 34. Form 172 for Proposal 62756, Second Version 
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Figure 35. Form 172 for Proposal 62756, First Version 





Dominion proposal received the same number on August 20. In this instance, 
the system was no doubt on a 2-week update cycle; hence, both 172' s were in 

the same input batch. It is now necessary to correct the ADP records in ad- 

dition to making any other non-ADP notifications to evaluators, proposers, 
etc. 

When this type of multiple input is made three things can happen to the 
Form 172 cards: 

1. Some of them will get on the proposal master file. 

2. Some of them will reject and error messages will appear on the 

error edit listing. 

3. Some of them will just vanish. 

It is only necessary to look at the end result on the proposal file listing 
to determine what happened in order to correct the existing record. Com- 
paring the listing, Figure 36, with the original 172 's in Figures 34 and 35 
leads to the following conclusions: 

1. University Name — Old Dominion is listed instead of Texas. (Note 
also that Texas was a card that was rejected and listed on the 
error edit list example used on page 60.) 

2. Reviewing Codes — GSFC and LARC are listed instead of LARC and 
ES. ES has disappeared. 

3. All information on the first two lines of the 172 describes the 
Old Dominion proposal rather than the Texas proposal. 

4. Proposal Title — There is a mixture of the two proposal titles 
shown on the list . 

This confused situation, once identified, is easily corrected in two steps: 

1. A new number is assigned to the Old Dominion proposal and a Form 
172 submitted as though nothing has happened. 

2. File maintenance is carried out directly on the data base to cor- 
rect all of the information associated with 62756, including chang- 
ing the name to Texas and any of the other information which is 
erroneous, i.e., entries which pertain to the Old Dominion proposal. 
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Figure 36. File Listing for Proposal 62756, Combined Version 



A full description of how this is accomplished through the use of 
Transcript No. 22 is presented in Part D, which follows. 

D. Basic Proposal Maintenance — Preparation of Transcript No. 22 

1. When to Prepare 

The Basic Proposal Maintenance (or File Maintenance, FM) Transcript 
is used to make direct changes to the data base. It is the most 
powerful type of input available in the system and, therefore, is 
used only when no other type of input is appropriate. Its main use 
is in correcting errors. It must also be used if a reviewing office 
decides to reject rather than fund a proposal previously designated 
as "intent-to-fund . " 

Important: Transcript No. 22 can only be used if the proposal num- 

ber is already in the data base. Physical reference to the file 
listing must be made in the process. 

An example of Transcript No. 22 was shown as Figure 25, in Chap- 
ter III, as part of the overall system flow description. In this 
part, the instructions for completion of each card on the form will 
be illustrated by showing the step-by-step preparation of a Trans- 
cript No. 22 to correct the error situation described above. The 
completed transcript is shown as Figure 37 at the end of the 
instruction section. 

2. Specific Completion Instructions 
a. TA Card 

— Proposal Control Enter the control number, 62756 , 

under the arrowhead exactly as shown 
on the file listing. The file list 
must be consulted before completing 
this card. 


Number 
cc 1-11 
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— Institution 
Name 

cc 12-35 


— Received 
cc 36-43 

— Prior Grant/ 
Contract Number 

cc 44-57 


— CONT 
cc 44-57 


— FICE Code 


Enter the name, TEXAS, UNIV -AUSTIN , 
starting under the arrowhead. The 
dotted line between columns 30 and 31 
indicates the end of the normal 20- 
space name. However, a total of 25 
spaces are available for the name, 
if required. 

Enter the date, 08-06-75 , to indicate 
the date the proposal was received 
by NASA. The style is always 00-00-00. 
Enter any combination of letters 
and/or numbers. In the example, the 
contract number is NSG-5005 . Spaces 
and symbols can also be used. If a 
number is entered by mistake, put an * 
in column 44. It will blank out the 
prior grant/contract number. 

The letter "C" in this column (not 
used in the example) indicates that 
the proposal is for a continuation 
but the prior grant /contract number 
is not known. If a "C" is on the 
file by mistake, insert an * in 
cc 58 . 

(Reserved. Do not use.) 


b. TC Card 

— Proposal Control 
Number 

cc 1-11 

— Proposed Cost 
cc 12-21 


(Same as for TA card.) 


Enter the exact dollar amount, right- 
justified. Do not use commas or $. 
Fill all the blank spaces with zeros. 
In the example, the dollar amount is 
entered as 0000011535. 
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— Principal 
Investigator 

cc 22-43 

— Date Acknowledged 
cc 44-51 


— U 


— OBJ & F.S 

— I 

cc 57 


Enter the last name first, followed 
by a comma and the initials or the 
first name, e.g., LAMBERT , D . L . 

Enter the date the proposal was re- 
ceived by NASA. This date does not 
appear on the file list, but can be 
obtained from the original 172. In 
the example, the date is given as 
08-07-75 . 

Enter "U" in this column to indicate 
that this is a university project. 
This must appear on all file records. 
(Reserved. Do not use.) 

"I" indicates "intent-to-fund" and 
this code is normally entered on 
Transcript No. 19. However, it may 
be used during error correction pro- 
cedures. The most common use of this 
column is to insert an * in order to 
delete an unwanted intent-to-fund 
proposal. The use of this column is 
not included in the example. 


c. TE Cards 

— Entire Proposal 
Title 

cc 12-77 


The entire proposal title must be 
entered in order to change any part 
of it. In the example, there is a 
one-line title entered. 


d. TG Cards 

These cards are used to modify information about evaluating, 
codes. New evaluating codes may be added using a TG card 
only if no additional distribution or evaluation results cards 
(Transcripts Nos. 18 and 19, respectively) are submitted at 
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the same time. It is never safe to take a TG card action un- 
less it is against an evaluating code already on the file 
listing. Furthermore, after a TG card action, the next file 
listing should be checked to ensure that the change was suc- 
cessful; if not, a new TG action is required. 

The most important aspect to observe in using the TG cards is 
that each one affects a specific evaluator position on the 
file listings Thus, the "REV" numbers 1-6 in column 78 relate 
to the "revcode" on the file listing. Using proposal 62756 
in Figure 37 as an example, GSFC falls on the line controlled 
by 1TG, LARC by 2TG and so forth, for a maximum of six evaluat- 
ing codes. Thus, in order to "hit" a particular evaluating 
code line in a proposal record it is essential that the pro- 
posal number be put on the appropriate REV TG card line. 

With reference to the TG card examples in Figure 25, repeated 
below, the following actions will occur: 
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The input on 1TG will change the reviewing code to LARC and 
the date sent to 02-15-75. (Any evaluation received date and 
results on the file will remain unchanged since columns 25-33 
are left blank.) 
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Figure 37. Use of Transcript No. 22 to Correct Proposal 62756 Record 























The input on the 2TG completely replaces whatever is on the 
record with the data input on the card. Note that no review- 
ing code is entered. This means that the reviewing code on 
the file is satisfactory and need not be changed. 

The 3TG illustrates correction of an error. An evaluation 
completion date and evaluation results were entered by mis- 
take on a Transcript No. 19. The asterisk removes the bad 
information. Note that the "date sent" is always entered for 
all of the actions, even if the same dates are already on 
the file. 

The final example on the 4TG shows how to completely remove 
all information, including the reviewing code, on the fourth 
evaluating code line in the proposal inventory. 

3. Error Messages 

As this transcript is designed for the particularly skillful oper- 
ator, there are only a limited number of error messages. Some of 
these are shown below. 

iKArvit,* l P 1 rtL. cl 

TA KC SCCH PRCPCSAl ON FILE 

ME HRCKU LIKE KUMBER 

X 

dlb hRONu L i Nb NUUbEK 

X 

The "no such proposal on file" results either from a keypunch error 
or failure to consult the file listing while preparing a Transcript 
No. 22. 

The "wrong line numbers" represents keypunch errors as there are no 
such cards as 5TE and 8TG. To correct the TE card error, all of 
the English must be re-input, even if three of the four lines are 
correct. 


cicic LMYfc«SiTY 

AAAAAAAAAXX 

c ltc 9 f 1. 1. ci-w L A *• PiCcl rtf' uPYiT***. untnln 

ilcso Pi 1 l- c l Aw /— c 3— / 'jL 
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Four additional edit messages are not illustrated. There will be 
a "non-numeric characters" message if the proposed cost contains 
anything but numbers. The remaining three edits are on the TG 
cards. "Missing or bad date sent" results if the date is impos- 
sible or if the date was not entered. "Missing or bad completed 
date" results from an impossible date or entry of an evaluation 
result (F or D) without entering a completed date. "F or D not 
indicated" results from entering a completed date, but not an 
evaluation result. 

E. Other Card Errors 

Three other types of errors with which the system operator will have to deal 
are shown in the sample error edit input list below. 

kc JLlT L b lui'ul _ . . REASON ...REJECTED 

Lrihfe i Id cMHlM . . .... _ . _ .. 

cz l ->1 uJL-C.?r_U- A KEY PUNCH E RROR OCCUREO 

XX 

. od/ud .rfANUtL Utsl.CN. ... . . A KEY PUNCH E PRO R_ OCCUR EC 

XX 

.. LucnKcCmUCN ilui/t xtT. hfeMl. T L R d 1 N t tL.ACtS, EvR.EoTuRE.au A. NET PUNCH ERROR OCCUR ED.. 

XX 

Uiui Ar.*._ ..ii. IsAZiLt l\j - zl- 1U -Z/ -7S A KEY PUNCH ER ROR_ GCC UREC 

XX 

Each of these involves a rejection as a result of missing card I.D.'s. These 
particular messages have been chosen to show that corrections are not always 
made by simple re-submission of the input card. To start with, 62757 at the 
top of the list is similar to those previously discussed. It was input on 
an additional distribution transcript and may be re-input the same way. 

However, the next two lines of English for 62760 were originally input on a 
Form 172. Since 172 can only be made once, a different error correction 
procedure is required. (Note also that the lines are out of order; without 
the card numbers the system cannot determine the proper sequence.) The 
first step in correction is to examine the file listing for 62760 below. 

There is no English description at all. Therefore, it is only necessary to 
put the English directly into the file on Transcript No. 22. 
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100u-«i WU7> 
PAGE wi«0 


.PUc-oAt-ci . . CuA MANAfccMEM 1 .\Fu*M A I I UN SYSTEM 

uf uAfe: Cl-iL-f? FRCPCSAl. flit LISTING 


LvM ALL 

_Gu<3U£d 


IS c(Ul,i, LIzHujl 

aiAf'i Llritfcl ui.z-tii£ -GuhllSib &IlCh-C E 


IN CASE 

££ Lh ££ IlUtEi I KAlUtt 




LLu «ifl IMwJ'i lMV ... . . . Cb-iC-7* NGKrii 7r CC 3“C 1 2 . CLAY, F, P. . VtOJ* 

woF*. .2 Cb-C7-7a CoS t F V AT I CN$ Cf EMISSION L IilcS IN M SUPERG l ANI S. 

~ LriAW ,J_ . .(Lo-k 1_- 4.5 " S H L 1 1 L E MATEF1 ALS LA_dC_PAI.C PY . 


c2i'Jt Fi\ i Ac c. I Lu un i ■ t a. ^ a f 1 


CS-C>-73 UUK C Sf T. A. 11417^ 

LS-C7-0 FJRMLLAIJCN Cf CCNTRCL LA"S FCR TILT -RGI CR VJOl AJKChAFT 


-icXI — LNi.k_.Lj- _ . TA E, & KGF F t. h , . 7j_*tOQ 

«iri l.j CS-C7-7> 


Ci/cl HmM-UiC LAiVchSlI) 


IC-0S-O PDLNO, G. M. co977 

2.9 LC-21-7? Trit INFLUENCE .CF CU-AOSCRPT ION GF OXYGEN AND AlnALI.MlIA 

2.9 1 C-tl-io LS LN THE UCPK FLNCTICN CF SINGLE CRYSTAL TUNuiT tN jUKm 

CyL,_. 


Finally, there are three evaluating codes and dates sent for 62761 (the last 
item on the input edit list). Since these are all on one line, they could 
only have come from the R1 card on the Form 172. Reference to the original 
172 will show that distribution was made to five offices, the three on the 
reject list and the two listed for the proposal on the file list above. 

Since a Form 172 cannot be resubmitted, the missing distribution is most 
easily handled by the Transcript No. 18 procedures for additional distribution. 

Also of interest is the reviewing code "ANRC" for proposal 62759 on the file 
list. By examining the input card list for this update run (see Figure 33, 
repeated on the next page) , it can be seen that the reviewing code was sub- 
mitted as "ARC." However, at the same time a request was submitted to 
change all ARC codes to ANRC. This illustrates the concept that a code 
change affects both new incoming data and data already on the file. 


72 



JkPuT UPC LJST 



GNFC GSFC 


TfcAASf UMV-AUSTlk 
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Figure 33 Repeated. Input Card List 
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APPENDIX 


A. Data Base and Special Features 

Figure 38 shows the actual file layout or record content of the data base, 
while Figure 39 relates the initial Form 172 input to the data base. Sev- 
eral fields are reserved or held for future expansion: 

1. The Office of Education version of the Federal Interagency Council 
on Education (FICE-OE , item #6) code uniquely identifies each recog- 
nized school listed in the annual Office of Education Directory. Pro- 
vision is made to input this code if more positive identification of 
schools is required. There is, however, no pre-programmed logic to 
use with the code. The code is not edited prior to file update, 
although it has a check digit. OE code assignments are randomized 
and are useful for matching and primary sorts. 

If this code is inserted and used in conjunction with an appropriate 
look-up table, standardized institution names can be used and addi- 
tional report writers can be developed. For instance, using the 
standard University Affairs look-up table shown in Figure 40, re- 
ports can be printed which (1) group all proposals from the same 
university by sorting on the FICE-OE code, (2) sort proposals alpha- 
betically by institution using the ALPHA code, and (3) sort propo- 
sals alphabetically by institution within state or country by using 
the OUA code. The NSF version of the FICE code is slightly different 
than the OE version. This becomes an important consideration when 
interagency data exchange is involved. 

2. The CASE (Committee on Academic Science and Engineering) Objective 
of Study code (CASE-OBJ, item #11) divides university support into 
descriptive categories specified for government-wide use by 0MB 
Circular A-46, "Standards for Statistical Surveys." Including 
these codes, shown in Figure 41, will allow analyses of "proposal 
pressure" to fund certain types of projects and analyses of rejec- 
tions and funding trends in the various categories. (NASA work 
falls only into objectives 01-04 and 06.) 
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RECORD CONTENT 



4. TYPE 

{ 1 o. C A«D CD**- T APE CD c * OISK □</. UI3T | |e. 



7. PARITY 

O- OOO Q6. even 



a. MODE 

I I O. LOAOl Ife. MOVE 


flnel. 1 ) 


d. SEQUENCE f Major-minor; use item numbers) 


•TANOARO 

LABEL 

i. 


CONT-ITUM 

INST 

DATE-REC 

MON-REC 

DASH-1 

DAY-REC 

DASH- 2 

YR-REC 

PRIOR-GC 

CONT-FLAG 

FICE-OE 

PRO-COST 

PRIN-INVEST 

DATE-ACK 

MON-ACK 

DASH- 3 

DAY-ACK 

DASH-4 

YR-ACK 

TYP-INST 

CASE-OBJ 

CASE-FIELD 

NARRAT1 

NARRAT2 

NARRAT3 

NARRAT4 

INTENT-FUND 

SEG-REV1 

REVIEW-OFC 

DATE-SENT- 1 


I LOCATION | 

BEGIN 

C. 

mi 

■ 1 

11 

12 

35 

36 

43 

36 

37 

38 

38 

39 

40 

41 

41 

42 

43 

44 

57 

58 

58 

59 

65 

66 

75 

76 

97 

98 

105 

98 

99 

100 

100 

101 

102 

103 

103 

104 

105 

106 

106 

107 

108 

109 

110 

111 

176 

177 

242 

243 

308 

309 

374 

375 

375 

376 

402 

376 

380 

381 

388 


10. DESCRIPTION 



Control Number 
Institution 
Date Received 
Mo Received 
Dash 

Day Received 
Dash 

Yr Received 
Prior G/C 
Continuation Flag 
FICE Code-OE Version 
Proposed Cost 
Principal Investigator 
Date Acknowledged 
Mon-Acknw 
Dash 

Day Acknowledged 
Dash 

Year Acknowledged 
Type of Institution 
Case Objective of Study Code 
Case Field of Science Code 
Title, Line 1 
Title, Line 2 
Title, Line 3 
Title, Line 4 
Intent to Fund 
Segment - Reviewer 1 
Reviewing Office 1 
Date Sent 1 
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MON-SENT-1 

DASH-5 

DAY-SENT-1 

DASH-6 

YR-SENT-1 

DATE-COMPL-1 

MON-COMP-1 

DASH- 7 

DAY-COMPL-1 

DASH-8 

YR-COMPL-1 


SEG-TAG1 
SEG-REV2 
SEG-REV3 
SEG-REV4 
S EG -REV 5 
SEG-REV6 
FILLER 


Mon-Sent 1 
Dash 

Day-Sent 1 
Dash 

Yr-Sent 1 
Date Completed 1 
Mo Completed 1 
Dash 

Day Completed 1 
Dash 

Yr Completed 1 
Evaluation Results 1 
Filler 

Segment - Reviewer 2 
Segment - Reviewer 3 
Segment - Reviewer 4 
Segment - Reviewer 5 
Segment - Reviewer 6 
Filler 



76 
























Card 

CC 

Label 

PI 

1-11 

CONT-NUM 

PI 

12-35 

INST 

PI 

36-43 

DATE-REC 

PI 

44-57 

PRIOR-GC 

PI 

58 

CONT-FLAG 

PI 

59-65 

FICE-OE 

P2 

1-11 

CONT-NUM 

P2 

12-21 

PRO-COST 

P2 

- 22-43 

PRIN-INVEST 

P2 

44-51 

DATE-ACK 

P2 

52 

TYP-INST 

P2 

53-54 

CASE -OBJ 

P2 

55-56 

CASE-FIELD 

P3 

1-11 

CONT-NUM 

P3 

12-77 

NARRAT1 

P4 

1-11 

CONT-NUM 

P4 

12-77 

NARRAT2 

P5 

1-11 

CONT-NUM 

P5 

12-77 

NARRAT3 

P6 

1-11 

CONT-NUM 

P6 

12-77 

NARRAT4 

Rl 

1-11 

CONT-NUM 

R1 

12-16 

REVIEW-OFC-1 

Rl 

17-24 

DATE-SENT-1 

Rl 

25-29 

REVIEW-OFC-2 

Rl 

30-37 

DATE-SENT-2 

Rl 

38-42 

REVIEW-OFC-3 

Rl 

43-50 

DATE-SENT-3 

Rl 

1-11 

CONT-NUM 

Rl 

12-16 

REV IEW-OFC - 4 

Rl 

17-24 

DATE-SENT-4 

Rl 

25-29 

REVIEW-OFC-5 

Rl 

30-31 

DATE-SENT-5 

Rl 

38-42 

REVIEW-OFC -6 

Rl 

43-50 

DATE-SENT-6 

NOTE: 

Sequential number of 

Reviewing Offices on the 


R1 cards has been arbitrarily assigned for con- 
venience. Actual sequencing on file is estab- 
lished by whatever random order the cards may 
be in during file creation. 


Figure 39. Form 172 Card Location— Data Base Relationships 
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Figure 40. University Cross-Coding Lookup Table (UNICODE 1A) 




Case Objective 
Code 


Name 


01 


02 

03 

04 


05 

06 
07 


Research and Development 
(11 — Basic Research) 

(12 — Applied Research) 

(13 — Development) 

Fellowships, Traineeships, 
and Training Grants 

R&D Plant 

Facilities and Equipment for 
Instruction in Science and 
Engineering 

General Support for Science 
and Engineering 

Other Activities Related to 
Science and Engineering 

All Other Activities 


Figure 41. CASE Objectives 

3. The CASE Field of Science code (CASE-FIELD, item #12) is in concept 
and use similar to the Objective code, except that it classifies 
technical effort into broad areas of science and engineering. Figure 
42 contains the field list specified in 0MB Circular A-46. 


14. FIELD OF SCIENCE or ENGINEERING (Circle the < 


• code number which represents the most uppropr iote field. See instructions on reverse,) 


PHYSICAL SCIENCES 

12 ASTRONOMY 
2? CHEMISTRY 
23 PHYSICS 

29 PHYSICAL 

SCIENCES. NEC * 

MA THEMATICS 
22. ANY DISC l PLINE1S) 


ENVIRONMENTAL SCIENCE 
(Terres trial and extraterrestr ial) 


32 ATMOSPHERIC SCIENCES 

32 GEOLOGICAL SCIENCES 

33 OCEANOGRAPHY 


39 ENVIRONMENTAL 
SCIENCES, NEC* 


ENGINEERING 

£2 AERONAUTICAL 

42 ASTRON AUTlC A L 

43 CHEMICAL 

44 CIVIL 

4 S ELECTRIC A L 
46 MECHANICAL 


’ A' of Elsewhere Classified (For interdisciplinary projects 
1 For interdisc ipl inary pfojects which cannot be classified 


47 METALLURGY 
AND MATERIA LS 
49 ENGINEERING, NEC 
and others not listed by discipline name) 
within any of the preceding main fields 


LIFE SCIENCES 

52 BIOLOGY 

52 CLINICAL MEDICAL 

53 OTHER MEDlCA L 

59 LIFE SCIENCES NEC- 
PSYCHOLOGICAL 
62 BIOLOGICA L 
62 SOCIAL ASPECTS 
69 PSYCHOLOGICAL. NEC 


SOCIAL SCIENCES 

72 ANTHROPOLOGY 

72 ECONOMICS 

73 HISTORY 

74 LINGUIST ICS 
75. POLITICAL SCIENCE] 
76 SOC IOLOGY 

79 SOCIAL SCIENCE 
NEC* 

OTHER SC IENCES •• 
99 ALL DISCI PLINE(S) 


Figure 42. CASE Fields of Science 
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4. 


Date acknowledged (DATE-ACK, item #9) is carried on the data base 
but not used. It is intended to be used in conjunction with the 
data received and the date sent for evaluation to monitor the tim- 
ing of the pre-distribution processing steps. It was not programmed 
for the present system as elapsed processing times rarely exceed 2 
days, thus requiring no special management attention. 

5. As may be seen in Figure 38, the file contains 550 characters, 43 

of which are blank. Five are assigned to each of the reviewing code 
segments while 13 are assigned to the file as a whole. They are re- 
served for future expansion. 

6. Type of Institution (TYP-INST, Item #10) is the takeoff point for 
multipurpose use of the system. By modifying the input edit to pass 
other codes (P-Industry, N-Nonprofit, H-Hospitals, G-Government , etc.), 
the input stream, edit, update and data base may be used to process 
and store a mixture of proposals. Prior to printing the file listing 
or any reports, simple interrogation of the TYP-INST code will allow 
completely separate printouts for each category. The system was de- 
signed with such an expansion in mind. A similar technique is pre- 
sently used for making the separation required to produce the "Intent- 
to-Fund" report (Figure 3) . 

A printout of the master file contents or data base is not necessary as 
the file listing (Figure 36) contains all of the data base fields except 
the acknowledgement date and the type of institution. 

The system has one additional file mainly of interest to the maintenance 
or systems programmer. It is an 80-character control file which contains 
four items: as-of-date, fiscal year start date (in terms of last day of 

the prior fiscal year), return code and override code. Re-start capability 
is available through the control file, as the return codes determine which 
programs are to be run. Thus, the maintenance programmer, on request, can 
perform unusual operations such as running the reports without the edits 
or year-end purge. Such actions are not normally required, but may be use- 
ful in recovering from a major systems problem. The system has been built 
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around a single master file concept, a file which can reside either on 
tape or disk; as a result it is portable with only minimal JCL changes. 
Further details on the ADP aspects of the system appear in the programming 
documentation, which is available with the source statement package. 

B. Specialized Program Actions 

Several specialized routines or approaches in the program will be of inter- 
est to those intimately involved in using, trouble-shooting or adapting 
the system. 

1. When any CODEx (x = 1 to 6) on the master file is updated (changed 
from or D) to F, all other CODEx fields in SEG-REV1 through SEG- 
REV6 are automatically updated with D, if_ the REVIEW-OFC associated 
with that SEG-REV is not blank. 

2. Whenever a D is automatically entered in a CODEx, as above, the com- 
pletion date associated with the F input which triggered the auto- 
matic routine is moved to DATE-COMPL fields associated with the D's. 

3. The MO-AGE (time under review in months) as shown on the file list 
is recalculated at each master file update. If the DISP column is 
blank, then the age is the difference between the date the proposal 
was received (DATE-REC or DT-RCVC) and the file "as-of" date. 

For a non-blank DISP column, the age is calculated using the receipt 
date and the date the action was completed (DATE-COMPL or DT-DISP) . 

4. The only effects of an I input on the R3 card, CC31, or the TC card, 
CC57, are to print out the associated proposal on the intent-to-fund 
list instead of the proposal Inventory and to count it only in sta- 
tistical table V. 

5. Input of an F in any CODEx automatically overlays the I, intent-to- 
fund, flag with a blank in the master file. (When I is input on the 
evaluation received transcript the CC14-16 and 21-28 are completed 
as for any other input. However, this is merely to simplify matters 
for the ADP clerks. With an I input, the entire file identifier is 
the proposal number; the other fields are ignored. 

6. When there is an entry on the Form 172 in the "continuation of" block, 
the system automatically enters C in the C block during file update. 
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7 . 


The annual purge removes all proposals with non-blank evaluation re- 
sults (all D's or one F and the rest, if any, D) . It also removes all 
REVIEW-OFCx and associated information for which CODEx = D. Thus, 
the master file does not give a complete review history (nor is it 
intended to) of a proposal which was partially reviewed in one fiscal 
year and carried over to the next fiscal year in an active status. 

8. The annual purge has a hard-coded safety lock-out. It will only run 
if the input as-of-date is October 1. A year must be listed, but 
the value is not critical. 

9. The file updates in input card number sequence, except for the delete 
(R4) and multiple code change (R5) which update last and next to last, 
respectively . 

10. The edit defines valid proposal numbers as those between 60000 and 
99999. This is an easily changed operational constraint. Only a 
minor program change is required to allow use of an 11-position alpha- 
numeric file identifier. 

11. If a change action having a proposal number greater than the last 
number already on the master file is input, the record will not up- 
date the master file or show up as a reject on its input edit list. 

It will vanish everywhere except on the input 80/80. This is a rare 
situation in normal operations and, of course, does not apply to 
Form 172 "add" input. 

12. The activity counter (Figure 26) physically counts the following 
items : 


Items Counted 


New Proposals 
Primary Distribution 
Secondary Distribution 
Evaluations Received 
Proposals Deleted 
Code Changes 

File Maintenance Records 


PI cards 

Number of review codes on R1 cards 
R2 cards 
R3 cards 
R4 cards 
R5 cards 
T cards 


13. Proposals are distributed on the monthly activity table (Figure 13) 
on the basis of the following master file fields: 
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Receipt Month - MON-REC 

Funding Month - MON-COMPL-x associated with CODEx = F 

Rejection Month - Where all CODEx = D, most recent MON- 

COMPL-x. This assumes a rejection letter 
is sent immediately after all reviews 
have been completed and in the same month. 
Except for possible "end-of-month" effects 
this approximation is close enough for man- 
agement analyses of rejection activity 
trends . 

The funding and rejection counts are mutually exclusive. Receipt- 
funding or receipt-rejection pairs in the internal count are valid. 

14. Form 172 instructions specify that commas are to be used in the pro- 
posed cost. This is merely for clerical convenience. The program 
accepts the field, as is, removing any blanks or commas during an 
internal zero fill and justification routine. On Transcript No. 22, 
however, any FM to the cost field must be in proper all-numeric, 
right-justified, zero-filled form. 

15. If a SEG-REV inadvertently reaches the master file with a missing 
REVIEW-OFC , the program will automatically delete the erroneous 
record. There is no error message. This situation can only arise 
from an improper TG card input . 


C . Adaptions — Correspondence Systems Example 

It has been mentioned earlier that the proposal handling system is a spe- 
cial version of a general correspondence system. Slight modifications in 
the broad program structure were made to adapt it to the specific purpose 
of tracking proposals. This section, therefore, will give an actual ex- 
ample of the simplicity with which the system can be applied to other 
needs . 


For this example, an existing manual correspondence control system has 
been chosen rather arbitrarily; it came to the author's attention as a 
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result of a letter referred for reply. Characteristics are of particu- 
lar importance: (1) ADP techniques are required only for tracking out- 

standing letters and ensuring timely replies (i.e., its function is active, 
not archival, as historical records are maintained manually) ; (2) all of the 
information needed for following the correspondence is available at the time 
of receipt and may be input to an ADP system on one Form — the equivalent of 
one set of cards; and (3) input techniques, edits and error messages must 
be easily handled by clerks with no ADP training to speak of. These are 
the exact main characteristics of the proposal system. To wit: 

1. The system does not maintain a permanent birth-to-death record of in- 
coming letters. At the end of the fiscal year completed items are de- 
leted from the file, leaving, however, statistical tables of the over- 
all performance of the various offices assigned to answer correspondence. 

2. The initial record form, "correspondence control," is shown in 
Figure 43. The maximum amount of information available at time of 
initial preparation is illustrated. This card is exactly analogous 
to the original copy of the Form 172. Figure 44 makes this point by 
using the proper Form 172 fields to input all of the data on the 
Correspondence Control Form (the "date sent" is a bonus, not avail- 
able on the Control Form) . 

For actual use, the Form 172 typography would, of course, have to be 
changed. The important point is that the system cannot distinguish 
between use of the 172 to input normal proposal material and its use 
as a pseudo Correspondence Control Form. 

3. The existing input and update techniques and forms are structurally 
the same. Thus, on the Form "172," use of the suspense date in the 
"continuation of" field automatically separates items without sus- 
pense dates ("new awards") from those with suspense dates ("continua- 
tions") in the statistical tables (see Chapter IIB, analytical tables). 
This also makes the suspense date appear on the file listing (Figure 
11) and the inventory report (Figure 2) in the "continuation of" 
area. 
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Figure 43. Typical Input for Existing Correspondence System 




NATIONAL AERONAUTICS AND SPACE ADMINISTRATION 
PROPOSAL STATUS RECORD 
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Figure 44. Use of Proposal System Generalized Capability in a 
Correspondence Control System 





Material inserted in the FICE code and OBJ fields is pre-programmed to 
go into the data base, even though these fields are not in current use 
in the proposal system. The U field is used as is, but redefined. 

Thus, a U is inserted to indicate that a definite written response is 
required. Use of 0 or N references "other" and "no" on the "reply 
necessary" block on the original correspondence control. Coding of 
this nature puts only items requiring a written response in the ADP 
system, leaving the trivial 0 or N categories for manual tracking, if 
any is required. Indeed, if an 0 or N date is inadvertently input it 
will fail edit ("U not indicated") . 

The evaluating code block is used to indicate that code P has received 
the action copy of the letter. When P completes the action, an F is 
entered on Transcript No. 19 (evaluation results. Figure 23) in the 
normal fashion, indicating "finished." On the other hand, if code P 
demurs and the action is transferred to another office, a D is entered 
on Transcript No. 19, while the newly responsible office is handled as 
"secondary distribution," using Transcript No. 18 (Figure 22). An of- 
fice may also request an extension of its suspense date. In this event 
the new data would be input on the File Maintenance Card TA, Transcript 
No. 22 (Figure 37). 

In summary, input, edit, update and master file creation procedures re- 
quire no structural modification to use the existing proposal system, 
in a common correspondence application. Thus, no new design or program- 
ming must be done for the most complex part of any ADP system. Cosmetic 
changes in headings and literals to reflect correspondence rather than 
proposal handling are trivial. The system is designed to calculate 
periods between dates in days. These are converted to months, as in 
the proposal application; by merely changing a divide instruction, they 
may be converted to weeks or even left as days. 
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Programming new or modified output reports, if desired, is a simple 
matter, given master file handling techniques. For example, an out- 
put report sequenced on suspense date might be desired. Even so, 
two output reports, the file listing and the inventory, can be used 
with only a few cosmetic changes. All of the analytical tables and 
some of the counters, however, may require more adjustment or sup- 
pression due to limited applicability. The nature of output result- 
ing from correspondence input in these areas is left as an exercise 
for the reader. 
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